Method and apparatus for configuring and controlling network resources in content delivery with distributed rules

ABSTRACT

An intermediate network element deployed in a content delivery network is disclosed. The content delivery network cooperates its content delivery effort with other intermediate network element with similar capabilities. Distributing rules that govern the operations of the intermediate network element(s) are presented. These include the framework of the intermediate network element(s), the format of indicating part or whole of a rule specification to be distributed, the format of signatures for intermediate network elements to discover each other, the format of signaling other intermediate network elements that a rule is distributed to, and the method of determining the intermediate network element to distribute a rule to. In addition, authoring rules that are specific to real time streaming of contents are disclosed. A set of rule evaluation conditions are revealed that can be triggered based on different criteria during the streaming of real time contents. A set of parameters from which rules can be based on is disclosed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/364,585, filed Mar. 18, 2002.

TECHNICAL FIELD

The invention relates to the field of content delivery in a datacommunications network. More particularly, this invention pertains tothe distributed control of data packets stream flowing through anintermediate network element, and the distributed control andconfiguration of network resources at a hierarchy of the intermediaries.The main intended use of this invention is to act as a proxy for contentstreaming, and providing content adaptation services in a distributedmanner.

BACKGROUND ART

Over the past decade, the Internet, or more specifically, the InternetProtocol (IP) based network, has seen a tremendous growth. Theproliferation of the Internet and the increasing number of Internetusers has resulted in extension and scaling problems for applications.This is especially true for applications designed for end-users, such asthe World Wide Web (WWW), and audio-visual streaming. The increased innetwork bandwidth and processing power can hardly catch up with thedemands of the increasing number of Internet users. This has resulted inlonger load time for WWW page request, and lost of quality in real-timeaudio-visual playback across the Internet. The effort to reduce suchundesirable effects has led to a wide deployment of intelligent networkelements at the network edge (i.e. nearer to the end-users).

The most common use of such intermediate network elements are tofunction as caching proxies, such as hyper text transfer protocol (HTTP)proxies and/or caches as described in an article “Hypertext TransferProtocol—HTTP/1.1”, IETF RFC 2616, June 1999, by Fielding, R., Gettys,J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee.These have been successful in reducing the network load at the WWWserver and accelerating WWW contents delivery to the end-users. However,as the number of end-users increases, the variety of web-browserconfigurations and platforms widens. Similarly, the range of webcontents is also broadening. Simply replicating static web contentscannot hope to sustain the ever-increasing demands from the end-users.

In addition, there has also been a noted increase in the deployment ofmultimedia streaming over the Internet. These usually employ thereal-time streaming protocol (RTSP) as session protocol to set up andtear down communications channel, and real-time transport protocol andreal-time control protocol (RTP/RTCP) for the actual transmission ofcontent data. The RTSP is disclosed for example, in “Real Time StreamingProtocol (RTSP)”, IETF RFC 2326, April 1998, by Schulzrinne, H., Rao,A., and Lanphier, R. The RTP/RTCP is disclosed for example, in “RTP: ATransport Protocol for Real-Time Applications”, IETF RFC 1889, January1996, by Schulzrinne, H., Casner, S., Frederick, R., and Jabcobson, V.Because of the versatile nature of Internet traffic, adaptation of themultimedia stream to the fluctuating traffic conditions is necessary toensure a smooth presentation to the end-user. Though RTCP provides ameans for end-users to report their communication status back to thesender, measures taken up by the sender based on receiver report canhardly be effective because the distance (network-sense) between thereceiver and sender is often large. As most end-users connects to theInternet via an intermediary of some sort, for instance, firewallgateways, Network Address Translator (NAT), or proxies, the intermediarypresent a good choice to perform adaptation services on behalf of thecontent originator.

Furthermore, as the Internet grows, so does the range of devices thatare used to access content from the Web. This diversification of browsertypes has accelerated with recent advancements in wireless Internettechnology, in which tiny handheld devices such as digital personalassistants (PDA) and mobile phones have built-in micro-browsers thatbrowse the Web, or play back audio/visual streams. Content authors canno longer develop content with the assumption that the created contentwill only be viewed by users using traditional desktop computers. Deviceindependence is now a critical consideration, as disclosed in “DeviceIndependence Principles”, W3C Working Draft, September 2001, by Gimson,R., et al.

A number of international standardization organizations have recognizedthe need to provide services originally available only at the networkcore (where the servers are located) to the network edge (where the endusers are located). For instance, the Internet Engineering Task Force(IETF) has recently set up working groups focusing on providing servicesat the network edges. The Open Pluggable Extensible Services (OPES)working group is one such effort. The OPES working group focuses onextending the current HTTP proxies from performing simple caching tasksto a whole suite of adaptation services. The framework of OPES isspecified in “A Model for Open Pluggable Edge Services”, IETF IntemetDraft, Work In Progress, November 2001, by Tomlison, G., Chen, R., andHofmann, M. There is also a Content Distribution Internetworking (CDI)working group that concentrates on collaborations between differentcontent distribution networks (CDN). Such collaboration efforts arebelieved to be able to further accelerate the delivery of contents tothe end user.

The current use of intermediaries in content delivery is mostlyrestricted to providing simple functionality such as HTTP caching, HTTPproxy, or RTSP proxy. This cannot hope to maintain the service leveldemanded by the users of today's Internet, as the number of end-usersincreases exponentially. Moreover, with the range of hardware devicesand software agents employed to retrieve contents by different users arealso broadening, content providers are finding it difficult to presentto the users a coherent set of contents are that suited to the user'sdevice and preferences.

Though various international bodies have recognized the above problems,and have acted to provide resolutions, their work could still beimproved on. The OPES framework described in focused on the operationsof a single intermediary, ignoring the current trend of collaborationsbetween content delivery networks. In addition, though the idea of theOPES framework is to perform content adaptation so as to enhance theuser experience in content retrieval, it focused only on parameters ofthe HTTP. This is not only inadequate for device independence, it alsodoes not cater to the growing number of audiovisual streamingapplications.

DISCLOSURE OF INVENTION

To solve the problem listed in section 3.3, the present invention allowscontent providers, access providers, and/or end-users to specify rulesgoverning the delivery of content via intermediate network elements.These rules can be distributed to other intermediaries along the contentflow path, to achieve the maximum efficiency and easier control ofnetwork resources. It is suitable for deployment by different contentdelivery networks, and can cooperate among one another. In addition, thecurrent invention allows rules to be specified that are speciallycatered for real time content streaming. The present invention alsodefines a mechanism to extend rules to be construct based on userpreferences, and device capabilities. Such a provision allows the ruleauthor to construct rules that can better adapt contents to achievedevice independence.

This invention involves the operations of one or more intermediatenetwork elements performing content delivery and adaptation betweenend-users and the content providers. The intermediate network element(also known as intermediary) will parse each data packets transferredbetween the end-user and the contents provider. When the data packetsmatches certain criteria as specified by a set of rules registered withthe intermediary, actions specified in the rules are carried out,usually results in the modification of the data packets. Rules in anintermediary can be distributed to other intermediaries which are moresuited to evaluate the rule and/or perform the adaptations. In addition,rules can also cater specially to real time streaming protocol, or beconstructed with delivery context parameters to achieve deviceindependence.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a framework of an Intermediate Network Element, showing thefunctional architecture of the intermediate network element as used inthe invention.

FIG. 2 shows nodes along the Content Path, and illustrates a typicalcontent flow path from the content server to the content user,traversing a single or plural number of intermediaries.

FIG. 3 shows example of ContentPath Structure, particularly showing thevalues stored in a ContentPath structure of the intermediaryfoo4.bar.com as marked by literal 204 in FIG. 2.

FIG. 4 shows a method of Extracting Intermediaries Information fromEmbedded Signature in Data Packets, particularly showing the flowdiagram of the method to extract intermediaries' signatures in the datapackets to construct/update the ContentPath structure.

FIG. 5 shows a method of Determining the Remote Intermediary toDistribute Rule, particularly showing the algorithm used to determinethe remote intermediary to distribute a rule to, given the distributionindication.

FIG. 6 shows a method of Parsing Rule with Distributed Rule Support,particularly showing the algorithm used to parse a rule with the focuson supporting distributed rules. The actually method of parsing the ruleto check for syntactical validity and evaluation of the rule is outsidethe scope of this document.

FIG. 7 shows a method of Determining the Remote. Intermediary toDistribute Rule in a Server-Client Model, particularly showing thealgorithm used to determine the remote intermediary to distribute a ruleto, given the distribution indication, in a server-client model.

BEST MODE FOR CARRYING OUT THE INVENTION

An apparatus and methods for distributed network resource management isdisclosed. To facilitate understanding of the invention, the followingdefinitions are used:

A “packet” is a self-contained unit of data of any possible format thatcould be delivered on a data network.

An “intermediary” and an “intermediate network element” are equivalent,and are used interchangeably, unless otherwise specified, to refer to agateway, a router or an intelligent network hub for which this inventionapplies to.

The term “current intermediary” or “current intermediate networkelement” refers to an intermediate network element that is processing adata packet, or a rule specification, depending on the context the termis used in.

The terms “content server” and “content user” are used with respect to asever-client model of information exchange. The content user, which isthe client, will send a single or plural number of data packets to thecontent server containing a request. Such data packets are known asrequest packets. The content server upon processing the request wouldreply with a single or plural number of data packets containing theresponse. Such data packets are referred to as response packets.

In distribution of rules, the term “target intermediary” or “targetintermediate network element” refers to the intermediate network elementof the current invention receiving the distributed rule. The term“distributing intermediary” or “distributing intermediate networkelement” refers to the intermediate network element of the currentinvention distributing the rules to other intermediaries.

In the following description, for purpose of explanation, specificnumbers, times, structures, and other parameters are set forth in orderto provide a thorough understanding of the present invention. However,it will be apparent to anyone skilled in the art that the presentinvention may be practiced without these specific details.

The intermediate network element for which the current invention appliesto, consists of the functional architecture as depicted in FIG. 1. Theintermediary consists of a gateway module (101), a rule engine (102), asingle or plural number of special packages (103), and the ruleinjection module (104).

The gateway module (101) is the collection of functional blocks thatimplement gateway or proxy functionalities. These can include, but notlimited to, HTTP proxies and/or caches, RTSP proxies, RTP/RTCP mixersand/or translators, and application level gateways (ALG). For instance,we consider an intermediary performing the role of a HTTP proxy. Thegateway module (101) would thus implements the functional component tohandle HTTP connections from the client side, the functional componentsto establish a HTTP connection to the server, or another HTTP proxy,based on the client side request, and the functional component to relayresponses from the server back to the client side. Effectively, thegateway module (101) is the functional component that implements theprotocols (eg HTTP, RTSP) for which the intermediary is an active partyof.

The rule engine module (102) parses through all or part of the datapackets that passes through the intermediate network element and matchesthese data packets to a set of criteria specified by a singular orplurality of rules. This is known as evaluation of rules. These rulesare specified in a logical unit known as a Rule Specification. A RuleSpecification can contain a singular or plural number of rules. When amatch is found, the corresponding action(s) specified in the rules is(are) triggered. This is known as the “firing of a rule”. The actionperformed can include, but not limited to, inserting contents to thedata packets, removing part or all of the contents from the datapackets, and modifying contents in the data packets. These insertion,removal, and modification of packets contents can be carried out on theintermediary, or some other remote machines dedicated to perform packetstransformations.

Examples of rules that are parsed by the Rule Engine (102) include rulewhich determines the bandwidth to be allocated to the data stream thatthe client is requesting. For instance, a rule may be specified in thefollowing high-level form:

-   “If network channel of client <=1 Mbps, then allocate 10 kbits for    data stream”. (Rule 1)

The rule engine module (102) implements the functionality to parse suchrules and determines if a match (i.e. if the end-user's network channelhas a capacity is less than or equals to 1 Mbps) occurs. The aboveexample also shows how the rules control the network resource allocationdecisions.

Another example of rules being parsed by the rule engine module (102)will be to determine the next intermediary or server to contact inresponse to a client's request received from the gateway module (101).Here, base on the parameters of the request, the request may be routedto a different server/intermediary. For instance, consider the followinghigh-level rules:

-   “If requested data is audio only, route request to    foo3.bar.com”(Rule 2a)-   “If requested data is audio and video, route request to    foo4.bar.com” (Rule 2b)

The rule engine module (102) is responsible in parsing and interpretingsuch rules, and determining if one of condition is met. When one is met,the rule engine module (102) will inform the gateway module (101) whichnext intermediary/server is selected, and the gateway module (101),which implements the actual functionality to communicate with othersusing the specific protocol, would proceed to route the request to theselected next intermediary/server.

The intermediary in the current invention can have zero, single orplural number of special packages (103). These special packages (103)are modules designed to enhance the rule engine module (102) byproviding specialized functionalities. For example, a Quality-of-Service(QoS) special package can be employed to assist the rule engine module(102) in understanding and evaluating rules that involves QoS parametersand conditions. The rule engine module (102) on its own can only parserules and try to find a match on the conditions spelt out by the rulespecifications. Using the example of (Rule 1a) above, the rule enginemodule (102) will need help to determine the actual capacity of thenetwork channel of the client. A special package (103) for evaluatingQoS parameters can be installed in the intermediary to evaluate suchexpression. The rule engine module (102) would query the QoS specialpackage (103) when it parses a rule specification that specifies a QoSparameter (such as bandwidth, delay, etc). The QoS special package (103)evaluates the value of the parameter in question and passed it back tothe rule engine module (102). From there, the rule engine module (102)can then proceed to check if a match has occurred in the conditionspecified by the rule specification. In this way, a modular design ofthe intermediary can be achieved. The rule engine module (102) performsthe job of parsing rule specifications. It utilizes different specialpackages (103) to evaluate the value of a parameter that is specified ina rule specification, and from the values, determines if a condition ismatched. In the current invention, a special package for evaluatingrules based on delivery context is set forth.

The rule injection module (104) is a module that dynamically loads andunloads rules to and from the rule engine module (102). It also providesthe interface for remote parties to dynamically register, activate orde-activate rules. This module is indispensable in supportingdistribution of rules through various intermediaries.

Initially, when the intermediary starts up, the rule injection module(104) will load an initial set of rule specifications, based on aconfiguration file or otherwise, from the storage of the intermediary.The rules specifications will be loaded to the rule engine module (102).When a client request (or server response data) arrives; the gatewaymodule will processing the clients request (or server response data),and pass it to the rule engine module (102) for rule parsing. The ruleengine module (103) will parse the rule specifications and try to seekfor a match in the conditions specified against the request (orresponse). While parsing these rules, the rule engine module (102) mayrequire assistant from special packages (103) to evaluate the value ofparameters.

The rule injection module (104) also allows rules to be dynamicallyloaded to the intermediary. For example, an administrator may remotelytransfer a new set of rule specifications to be installed on theintermediary. Alternatively, the administrator may want to remotelyremove a rule specification from the intermediary. The rule injectionmodule (104) handles such remote operations. In addition, theseoperations need not be limited to human administrators. Indeed, thefirst portion of the current invention details the mechanism that allowsrule specifications to be loaded and unloaded dynamically betweenintermediaries. The rule injection module (104) plays the role here ofaccepting connections from other intermediaries and handle requests toload or unload a rule specification to/from the rule engine module(102).

Distribution of rules implies that rule specification(s) that is (are)loaded on one intermediary can be passed to another intermediary to beevaluated. Whole or part of the rule specification may be indicated tobe distributed. These indications also suggested to which intermediaryalong the data flow path to distribute to. FIG. 2 shows a typicalcontent flow path. Note that there may be other network elementsperforming relaying task along the content path that are not shown inFIG. 2. Along the path from the content server (201) to the content user(207), there may be a single or plural number of intermediaries(202-206) with the current invention employed.

Authors of the rule specification can indicate which intermediary alongthe content flow path to distribute the rule specification partially orwholly. Since it is unreasonable for authors to know how intermediariesare deployed in an actual real world situation, authors specify thepreferred intermediary where the rule is distributed to by indicatingthe direction of the distribution, i.e. towards the source node ortowards the destination node. The term “source” and “destination” areused with respect to the data packets. The source node is the node thatgenerates the data packet, and the destination node is the node thatconsumes the data packet. In a server-client model, the directions maybe specified as “towards server” or “towards client”.

For example, using the deployment scenario as illustrated in FIG. 2, arule specification is submitted to the intermediate network elementfoo4.bar.com (204). A part of the rule is indicated to be distributedtowards the “destination”. When processing a request packet, i.e. packetsent from the content user (207) to the content server (201) thisportion of the rule specification can be distributed to the intermediaryfoo2.bar.com (202) or the intermediary foo3.bar.com (203). Conversely,when processing a response packet, the same portion of the rulespecification can be distributed to the intermediate network elementfoo6.bar.com (206) or the network element foo5.bar.com (205). Similarly,when a part of the rule is indicated to be distributed towards the“server”, it can be distributed to the intermediary foo2.bar.com (202)or the intermediary foo3.bar.com (203). Conversely, when a portion ofthe rule specification is indicated to be distributed towards the“client”, that portion of the rule specification can be distributed tothe intermediate network element foo6.bar.com (206) or the networkelement foo5.bar.com (205).

One objective of the current invention is to allow rule authors to beable to specify a rule hierarchy where the topmost level of the rulespecification resides on one intermediary and the lower level portionsof the rule specification reside on other intermediaries. This allowsefficient control of the intermediary operations. Thus, in addition tospecifying the direction at which distributed rules should flow (i.e.forward, backward, towards content server or towards content user), thecurrent invention also allows rule authors to specify the approximatelocation in that direction where the rule should be distributed.

Using the above example, a rule author may specify the distributedportion of the rule specification to be distributed to the intermediaryas near to the content user as possible. In FIG. 2, this implies theintermediary foo6.bar.com (206). Alternatively, a portion of the rulemight be specified to be distributed to the intermediary one hop awayfrom the element nearest to the content user. In FIG. 2, this impliesthe intermediate network element foo5.bar.com (205). Similarly, it ispossible for the rule author to specify that a portion of the rule to bedistributed to the next intermediary towards the content server. Usingthe previous example where the rule specification is submitted tofoo4.bar.com (204), this means the rule author wanted the portion of therule to be distributed to the network element foo3.bar.com (203).

The current invention covers all the afore-mentioned means of markingthe rule specification for distribution. As an illustration, thefollowing character-based indication methods are presented. It should beapparent to anyone skilled in the art that other forms of indicationscan be used to achieve equal effect, such as using numeric oralphanumeric codes. In the character-based indications, each indicationsis of the form <target direction>-<approximate location from target> orof the form <approximate location towards target>-<targetdirection>where <target-direction> is the term source, destination,server or client, and <approximate location from target> and<approximate location towards target> are numerical values indicatingthe number of intermediaries away from the specified target.

For instance, to indicate the portion of rule to be distributed to theintermediary nearest to the content server, the rule author may use anindication of server-1 to show that the rule should be distributed tothe intermediary that is 1 hop away from the content server. When theindication of 2-server is used, the rule author expressed the desire todistribute the rule to an intermediary that is 2 hops away from theintermediary where the rule is loaded, towards the direction of thecontent server. Similarly, the indication client-2 indicates the ruleshould be distributed to the intermediate network element that is 2 hopsaway from the content user, and the indication 1-client indicates thatthe rule should be distributed to the next intermediary in the directionof the content user.

In order for intermediaries to distribute rule specifications amongthemselves, the intermediaries must have a way to first discover theexistence of other intermediaries on a given content flow path. Eachintermediary may also be connected to multiple content servers, contentusers and other intermediaries, thus discovery may not be feasible to beperformed statically using configuration files, nor one-shot at systemstarts up.

The present invention requires that intermediary to embed an indicationof their presence in the content as data packets flows from the contentuser to the content server and vice versa. Such an indication is knownas the signature of the intermediary. These signatures should containinformation of the intermediary, such as the resolvable hostname and thecapabilities of the intermediary. Capability of the intermediariesshould clearly indicate that the intermediary support distributed rules,and should also include information such as the special packagesinstalled in the intermediary.

For example, in the HTTP and RTSP protocols, intermediaries can appendtheir signature to the “Via” general header found in the request andresponse headers. An intermediary of hostname foo4.bar.com withinstalled QoS special package can insert the following “Via” headerfield as its signature:

-   -   Via: 1.1 foo4.bar.com (OPES=standard,qos,distributed)

For other protocols which do not have built-in mechanism forintermediaries to embed their signature, other means could be soughtfor. For instance, protocols usually provide the functionality formachines to embed optional information into the data packets (normallyusing optional extension headers). This can be used to carry signaturesof the intermediary. In addition, the above example used characterstrings as the signature for ease of understanding. It should beapparent to anyone skilled in the art that other forms of signature canbe used to achieve equal effect, such as using numeric or alphanumericcodes, so long as an external entity can extract the hostname andcapabilities of the intermediary from the signature.

In both cases where the protocol built-in mechanism is used, or optionalextension is used, multiple signatures should be allowed so thatsignature of each subsequent intermediary can be appended. In otherwords, when a data packet reach any given intermediate network elementin the content flow path, the intermediate network element knows theother intermediaries the data packet has previously traversed. This alsoenables the intermediary to know the order of the intermediaries thepacket traversed.

In a typical operation, there will be request flowing from the contentuser to the content server, and the response flowing from the contentserver to the content user. Intermediaries will thus know all otherintermediaries along the content flow path once a pair of request andresponse data packets passed through them. For instance, using thescenario shown in FIG. 2, the intermediary foo4.bar.com (204) will knowthe existence of the intermediaries foo6.bar.com (206) and foo5.bar.com(205) when the request from the content user (207) reaches it. When thecontent response from the content server reaches foo4.bar.com (204), theintermediary will discover the existence of the intermediate networkelements foo2.bar.com (202) and foo3.bar.com (203). Thus, theintermediary foo4.bar.com (204) will be able to detect the presence ofother intermediate network elements in the entire content flow path.

Intermediaries will maintain a cache of known intermediaries networkalong any given content flow path. The reason for doing so is explainedbelow. When an intermediary received a request, it may be necessary forit to distribute a rule to another intermediate network element towardsthe content server. If the intermediary relies only on the embeddedsignature to discover other intermediate network elements, it cannotknow in advance other intermediaries in the forward path towards thecontent server, until it receives the content response. Should such asituation arise, the rule engine module (102) should check if it couldretrieve information of intermediaries from its cache. If it can, thenthe rule can be distributed to a forward intermediary; else, the ruleshould be evaluated locally.

To maintain the cache, the data formats as shown in Data Format 1 and.Data Format 2 below can be used. Data Format 1 is used to record thehost identification (stored in the field hostname) and capabilities(stored in the field capabilities) of the intermediary. Data Format 2 isused to record the list of known intermediaries along a given contentflow path. The content flow path is uniquely specified by the source(stored in the field source), destination (stored in the fielddestination), and protocol (stored in the field protocol) triplet,expressed as {source, destination, protocol}. The num_nodes field storethe number of intermediate network element that a data packet from thesource node must traverse before reaching the destination node startingfrom (but excluding) the current intermediary, and the nodes array storethe information of each of such intermediate network element. FIG. 3illustrates a pair of ContentPath data formats stored in theintermediary foo4.bar.com (204) in the scenario depicted FIG. 2.

Data Format 1: Intermediary Entry struct IntermediaryEntry { NodeIDhostname; char capabilities[ ]; }

Data Format 2: Data Flow Path Information struct ContentPath { NodeIDsource; NodeID destination; ProtocolType protocol; int num_nodes; structIntermediaryEntry nodes[ ]; }

FIG. 4 depicts the method devised to extract the intermediaries'signatures embedded in the data packets and construct/update theContentPath structure. When a data packet arrives, the intermediaryfirst check if there is any signature embedded, as shown in the stepmarked with literal 401. If there is one, a ContentPath structure issearched from the cache that matches the {destination, source,protocol}triplet, as shown in step marked with literal 402. Note thatthe source of the data packet is checked for againstContentPath.destination, and vice versa. The reason for this is becausethe ContentPath structure is used to give the list of intermediariestowards the destination node, whereas when extracting signatures fromthe data packets, the intermediaries are given from the source node.Thus, there is a need to swap the destination and source nodes whensearching for a match.

If none can be found, a new ContentPath structure is allocated, as shownin step marked with literal 403. When a cached ContentPath structure islocated, the num_nodes and nodes fields will be purged, as shown in thestep marked with literal 404. A last-in-first-out stack to store thesignatures temporarily is then initialised to be empty and the counter nis set to zero in the step marked with literal 405. In the step markedwith literal 406, each embedded signature is extracted and pushed to thestack. In addition, the counter n is incremented to record the number ofsignatures extracted. When all signatures are extracted, the counter nwill contain the number of intermediaries before the current networkelement in the content flow path. This is stored to the num_nodes field.Signatures in the stack are then popped out to update the nodes array,as shown in the step marked with literal 406.

Previous description has presented the method for intermediaries todiscover other intermediaries along the content flow path. When a ruleengine module parses a rule specification and found that a portion ofthe rule specification is marked to be distributed, it can then checkthe appropriate ContentPath structure (by using the content server,content user, and protocol triplet) and determine which remoteintermediaries to distribute the rule to.

FIG. 5 shows the algorithm used to determine the remote intermediary todistribute the rule to, given the indication of distribution in the formof

-   <target direction>-<approximate location from target> or-   <approximate location towards target>-<target direction>    as previously described. The term target is used to denote the    numerical value of <approximate location towards target> or    <approximate location from target>. The term directive contains the    value “from” if the first form is used, and the value “to” if the    second form is used. The term direction is the value “source” or the    value “destination”. The term src, dst and protocol refers to the    source, destination and protocol extracted from the data packet    respectively.

The algorithm first searches for the ContentPath data format as shown inthe steps marked with 501 through 504. If the direction of distributionis towards the destination, the triplet {src, dst protocol} is used tolocate the ContentPath, as shown in the step marked with literal 502.Else, the triplet {dst, src, protocol} is used instead, as shown in thestep marked with literal 503. If no ContentPath can be found, thealgorithm returns NULL, as shown in the step marked with literal 512. Inthe steps marked with 505 and 506, target in checked to prevent it fromexceeding the number of remote intermediaries in the direction ofdistribution. In the step marked with literal 507, the distributionindication is checked to see if it is in the form

-   <target direction>-<approximate location from target> or-   <approximate location towards target>-<target directions

For the first form, the numerical value indicates the number ofintermediary from the end host (content server or content user).However, the intermediaries are listed in nodes array in the order ofthe direction towards the end node. Thus, in the step marked withliteral 508, a temporary variable x is set to the number ofintermediaries minus the numerical value target. Conversely, if theindication is in the second form, then the temporary variable x is setto the numerical value target minus 1, as shown in the step marked withliteral 509. The reason to subtract one is because the first element inthe nodes array is assumed to be nodes[0]. Anyone skilled in the art caneasily modify the above formulae to suit other kinds of arrayarrangement. In the step marked with literal 510, the variable x ischecked to see if falls out of range. If it does, the algorithm returnsNULL to indicate no suitable remote intermediary can be found, as shownin the steps marked with literal 512. Else, the function returns theremote intermediary given in nodes[x], as shown in the step marked withliteral 511.

FIG. 6 shows the method of parsing a rule specification with theconsideration of distributing rules. The rule specification is firstparsed to check for syntactical validity, and invalid rules arerejected, as shown in the steps marked with 601, 602, and 603. The ruleis next checked to see if the it is marked to be distributed, as shownin step marked with literal 604. If it is not marked, the rule isevaluated locally (605). Else, the algorithm depicted in FIG. 4 is usedto identify the remote intermediary to distribute the rule to, as shownin the step marked with literal 606. If the algorithm returns NULL, thatmeans no suitable remote intermediary can be found, then the rule isevaluated locally, as shown in steps marked with 607 and 605. When aremote intermediary is found, it is checked to see if it supports thespecial package required by the rule, as shown in step marked withliteral 608. If it does not, the rule is evaluated locally (605). If itdoes, the rule is then distributed (609). The whole process is repeatedfor the next rule to be parsed (610).

If a server-client model is used, where the target direction can bespecified by towards “server” or towards “client” instead, then themethod of locating the target intermediary given in FIG. 5 can no longerbe used. FIG. 7 shows the method for a server-client model. The onlydifference between the algorithm in FIG. 7 and the one in FIG. 5 is inthe steps marked with literals 701 through 703, and the steps markedwith literals 501 through 503. In the step marked with literal 701, thetarget direction is first checked if it is towards server or client. Ifthe target direction is server, the ContentPath is searched using the{node identification of client, node identification of server, protocol}triplet, as shown in the step marked with literal 702. If the targetdirection is client, the ContentPath is searched using the {nodeidentification of server, node identification of client, protocol}triplet, as shown in the step marked with literal 703. The remainingsteps marked with literals 704 through 712 are identical to the stepsmarked with literal 504 through 512.

In order to distribute the rule, the intermediary needs to signal thereceiving intermediary. For ease of explanation, the scenario that isillustrated in FIG. 2 is used. For the following discussion, theintermediary foo4.bar.com (204) is the network element that loads therule, and it has determined that the rule needs to be distributed to theintermediary foo6.bar.com (206) for evaluation.

To signal foo6.bar.com (206), foo4.bar.com (204) can embed a signal intothe data packet. The present invention requires that the embedded signalcontain the identifier of the intermediary that is distributing therule, the identifier of the intended intermediary receiving the rule,and the rule identifier that uniquely identifies the rule to bedistributed. The rule identifier must uniquely identify the portion ofthe rule specification on a given intermediary that is to bedistributed, and the identifier should not vary with time.

For example, in the HTTP and RTSP protocols, intermediaries can appendtokens to the “Pragma” general header in the request and responseheaders. Thus, the current invention can make use of this to embed therequired signals. For example, foo4.bar.com can append the followingtoken

-   OPES-distributed=“foo6.bar.com:XYZABC@foo4.bar.com”; to the “Pragma”    general header of the response. The token used is of the form-   OPES-distributed=“<target>:<rule identifier>@<distributor>” where    <target> refers the hostname of the intermediary to receive the    distributed rule, <rule identifier> refers to the unique identifier    to identify the distributed rule, and <distributor> refers to the    intermediary that is distributing the rule.

For other protocols which do not have built-in mechanism forintermediaries to embed signals, other means could be sought for. Forinstance, protocols usually provide the functionality for machines toembed optional information into the data packets (normally usingoptional extension headers). This can be used to carry signals forintermediary. In addition, the above example used character strings asthe signature for ease of understanding. It should be apparent to anyoneskilled in the art that other forms of signature can be used to achieveequal effect, such as using numeric or alphanumeric codes, so long as anexternal entity can extract the hostname of the distributingintermediaries, hostname of the target intermediary and the ruleidentifier from the signal.

In both cases where the protocol built-in mechanism is used, or optionalextension is used, multiple sign-als should be allowed so that two ormore sets of rules can be distributed at a single passing of a datapacket. Every intermediary must inspect the data packets to detect suchsignals, and check if the signal is intended for it. Once it determinedthe signal is intended for it, the intermediary can optionally removethe signal from the data packet.

The rule identifier is used to retrieve the actual rule from thedistributing intermediary using a separate communications channel. Therule injection module (104) is responsible for establishing such acommunications channel and retrieving/passing any distributed rule. Thecurrent invention does not specify the format of such a communicationschannel. Because the rule identifier is unique given a specifiedintermediary, intermediaries should cache the retrieved distributed ruleusing the rule identifier and the hostname of the distributingintermediary as a cache key. This eliminates the need to retrieve thesame distributed rule should a subsequent distribution occur again.

The above mechanisms can be deployed for contents distribution wherethere is a plurality of sending and receiving nodes. Such situation isdecomposed into multiple data flow paths, each containing one sendingnode and one receiving node. Note that this decomposition is only usedfor the construction of the ContentPath structure as describedpreviously. When an actual data that arrives at an intermediary that issent to plurality of receiving nodes, the intermediary can then decideon the rule distribution based on each ContentPath structure for eachcorresponding sending node (i.e. source) and receiving node (i.e.destination) pair. If the targeted intermediary to distribute a rule tohappens to be the same, then a single signal can be embedded onto thecontent. If more than one target intermediary is identified (because thecontent path split somewhere along the line), one separate signal foreach targeted intermediary can be embedded into the content.

In the previous descriptions, the intermediate network for distributionof rule is revealed. This document will, in the following discussions,turn to the next portion of the current invention, which narrows thedeployment of the current invention to real time content streamingsituation. In this situation, the content user sends a request to thecontent server, via a single or plural number of intermediary(intermediaries) which is (are) the object(s) of the current invention,to set up a real time session. When the content server accepts therequest with an appropriate response, a communications channel is set upbetween the content server and the content user through the intermediary(intermediaries). This communications channel between the content serverand content user is hereafter referred to as the content session. Thecontent server starts transmitting data packets through the contentsession to the content user without any active request from the contentuser, until the content user sends a request, via the intermediary, totear down the content session. Such data packets sent spontaneously bythe content server are henceforth referred to as content packets. Duringthe course of the transmission of content packets by the content server,the content user may or may not transmit information about thetransmission statistics back to the content server. Such statistics arehereafter referred to as feedback packets.

One existing protocol that fits the above description is the Real TimeStreaming Protocol (RTSP). However, the current invention can be appliedto other protocols that exhibit the same behaviour previously described,as should be apparent to anyone skilled in the art.

For all known prior arts, rules are evaluated for each request and/orresponse packets that passes through the intermediary. The currentinvention extends this by providing the capability for rule authors tospecify rules that are evaluated whenever a content packet passesthrough the intermediary, rules that are evaluated whenever a specifiesmultiple of content packets passes through the intermediary, rules thatare evaluated when a feedback packet passes through the intermediary,and rules that are evaluated at a specified regular interval throughoutthe duration when the content session is established. To attain suchprovision, rule authors are allowed to tag each rule with a specialattribute. For purpose of explanation, the attribute is referred to asthe “evaluateOn” attribute. Table 1 below listed the possible values ofthe “evaluateOn” attributes. Anyone skilled in the art should recognizedthat the current invention can be deployed using other names.

TABLE 1 “evaluateOn” Attributes “evaluateOn” Attribute Description“request” the rule is to be evaluated upon the reception by theintermediary of a request packet from the content user to the contentserver “response” the rule is to be evaluated upon the reception by theintermediary of a response packet from the content server to the contentuser “content” the rule is to be evaluated upon the reception by theintermediary of a content packet from the content server to the contentuser “feedback” the rule is to be evaluated upon the reception by theintermediary of a feedback packet from the content user to the contentserver “x-contents” the rule is to be evaluated upon the reception bythe intermediary of x multiple number of content packets from thecontent server to the content user, where x is a specified numericalvalue “t-seconds” the rule is to be evaluated when a content packet isreceived upon elapsed of every t seconds interval for as long as thecontent session is established, where t is a specified numerical value

The last part of the current invention concerns the employment ofspecial packages (103). As described earlier, special packages (103) aremodules that enable the rule engine module (102) to evaluate rulesinvolving different set of parameters (such as Quality of Service). Thecurrent invention defines a new special package, known as the “DeliveryContext” special package. This package will allow the rule engine module(102) to interpret rules that are constructed based on delivery context.Four major classes of delivery context are defined, as shown in Table 2below. These are User Preferences, Agent Capabilities, DeviceCapabilities, and Natural Environment. User Preferences refers toinformation about the human user, including browsing preference,language preferences, display preferences, QoS preferences, age groupand gender. Agent Capabilities provide information on the softwareagent, such as the agent type, supported formats, supported languages,and supported transport protocols. Device Capabilities refers to theinformation about the hardware device, which include the device type,processor speed and type, memory capacity, screen resolution and depth,and operating systems. Natural Environment provide information about thenatural environment surrounding the end user, including whether the enduser is indoor or outdoor, the end user's velocity, location of the enduser, and illumination properties.

TABLE 2 Delivery Context Parameters Parameters Values User Preferences“browsing- descriptive text about the user's browsing preference”preferences, such as text only, image sizes, handicaps accessibilitiesoptions, searching and filtering preferences “language- descriptive textabout user's order of language preference” preferences “display-descriptive text about user's color preferences, preference” full screenor window “age-group” descriptive text about the user's age group“gender” descriptive text about the user's gender “employment”descriptive text about the user's job nature Agent Capabilities“agent-type” descriptive text about the software agent “supported-descriptive text about the content formats formats” supported, andcontent encoding supports “supported- descriptive text about thelanguage supported languages” by the software agent “supported-descriptive text about the transmission protocols” protocols supportedby the software agent, and whether it has multicasting, broadcastingcapabilities Device Capabilities “device-type” descriptive text aboutthe device type “processor” descriptive text about processor speed andfamily “memory- descriptive text about memory capacity of the capacity”physical and secondary memory “screen” descriptive text about resolutionand depth “operating- descriptive text about the operating systemsystem” type Natural Environment “location” descriptive text about theuser's location, such as indoor or outdoor, and the locale “mobility”descriptive text about the user's mobility, whether fixed or moving, andthe velocity if moving “illuminations” descriptive text aboutilluminations surrounding the end user

The Delivery Context special package interprets rules that areconstructed using parameters that are from delivery context. There arevarious methods where the delivery context special package can obtainthe actual values of the parameters. One method is to establish acommunications channel with an external entity that provides knowledgeof such parameters, for example the content user. For parameters such asthe Device Capabilities, it might be necessary to obtain it from thecontent user directly. An alternative method is to obtain it fromanother module that resides on the intermediary. This module may gatherthe values locally, load the values from a storage device or request thevalues from an external entity. For parameters such as the NaturalEnvironment, the intermediary may be able to deduce the information onits own, especially when the intermediary is located near the contentuser. For parameters such as the User Preferences, the human user mayhave registered a set of profiles to be stored at the intermediary.

The invention allows intermediate network elements along a content flowpath to actively collaborate their content delivery efforts to enhanceuser experience in content retrieval. With more and more contentdelivery networks (CDN) deployed in the Internet, the inventiondisclosed in this document allows intermediaries of such CDNs toorchestrate their efforts by the provision of distributed rules. Rulesloaded on one network element can be distributed to other intermediariesin real time, so that adaptation of data contents and contents requestcan be performed at a more suitable node. It also allows better controlover the operations of content delivery.

In addition, the disclosed invention contains methods and means whichare specific to the real-time delivery of Audio Visual content in apacket switch network. This allows rule authors to create rules that canreact to fluctuations in the network conditions of the content streamingmore speedily. Authors can also create rules that are based on thedevice capabilities and user preferences of the content consumers. Whensuch rules are authored carefully with suitable adaptation services, theoverall user experience in content retrieval will be significantlyenhanced.

1. A network control framework apparatus for controlling resources at anintermediate network element connecting at least two communicationsnetworks, comprising: a gateway providing gateway functionality; a ruleengine that performs a network resource control decision based on atleast one specified rule, the at least one specified rule beingspecified according to a rule specification format; at least one specialpackage added to the rule engine that provides a specializedfunctionality to the rule engine; a rule injector that injects orremoves the at least one specified rule to or from the rule engine; anda distributor that distributes the at least one specified rule to theintermediate network element, comprising: a distributor that distributesindications that indicate whether at least part of the at least onespecified rule is to be distributed; a distributor that distributes asignature embedded in a data packet to announce capabilities of theintermediate network element that the data packet traversed; a parserthat parses the at least one specified rule to determine whether atleast part of the at least one specified rule is distributed; anidentifier that identifies a target network element to distribute atleast part of the at least one specified rule; a distributor thatdistributes signaling data embedded in the data packet that informs thetarget network element to distribute at least part of the at least onespecified rule; and a retriever that retrieves at least part of the atleast one specified rule distributed to the target network element fromthe intermediate network element that distributes at least part of theat least one specified rule.
 2. The network control framework apparatusas recited in claim 1, wherein a format of the indications for the atleast one specified rule for distribution comprises: a specification ofa direction of distribution by specifying an endpoint of the direction;a specification of a number of intermediate network elements between astarting point and the endpoint; and at least one of a specification ofthe number of intermediate network elements from the endpoint, andspecific content distributed at the intermediate network elements. 3.The network control framework apparatus as recited in claim 1, wherein aformat of the signature embedded in the data packet comprises: anidentification of the intermediate network element specified by thesignature; the at least one special package that is installed on the oneintermediate network element specified by the signature; and anindication that specifies a capability of accepting or generating atleast part of the at least one specified rule for distribution.
 4. Thenetwork control framework apparatus as recited in claim 1, wherein thesignature of the intermediate network element that the data packettraversed are stored with a starting point and an endpoint that the datapacket traversed corresponding to a traversal order for the data packetand a transmission protocol to which the data packet belongs.
 5. Thenetwork control framework apparatus as recited in claim 1, wherein aformat of the signature embedded in the data packet comprises: anidentification of the intermediate network element; and anidentification of the at least one special package installed on theintermediate network element.
 6. The network control framework apparatusas recited in claim 1, wherein a format of the signature embedded in thedata packet comprises: an identification of an endpoint that the datapacket flows to; an identification of a starting point that the datapacket flows from; a transmission protocol to which the data packetbelongs; a signature array of intermediate network elements in an ordercorresponding to a traversal order of the data packet, from oneintermediate network element where the format of the signature embeddedin the data packet is stored, to the endpoint; and a number ofsignatures of the intermediate network elements in the ordercorresponding to the traversal order of the data packet from the oneintermediate network element where the format of the signature embeddedin the data packet is stored to the endpoint.
 7. The network controlframework apparatus as recited in claim 1, further comprising: asignaler that signals the intermediate network element to express adesire to distribute a collection of specified rules to the intermediatenetwork element, comprising: an identification of an intermediatenetwork element to which the collection of specified rules isdistributed; an identification of an intermediate network element fromwhich the collection of specified rules is distributed; and anidentification of the collection of specified rules.
 8. The networkcontrol framework apparatus as recited in claim 1, further comprising: aretriever that retrieves a collection of specified rules, from theintermediate network element that distributes the collection ofspecified rules, by the intermediate network element to which thecollection of specified rules is distributed, comprising: a channelestablisher that establishes a communication channel between theintermediate network element where the collection of specified rules isdistributed to and the intermediate network element where the collectionof specified rules is distributed from; an identification provider thatprovides an identification of the collection of specified rules that isdistributed via the communication channel by the intermediate networkelement to which the collection of specified rules is distributed; and atransmitter that transmits the collection of specified rules that isdistributed via the communication channel by the intermediate networkelement from which the collection of specified rules is distributed. 9.The network control framework apparatus as recited in claim 1, whereinthe at least two communications networks comprise a client node thatsends a request to a server node via the intermediate network element,wherein the server node accepts the request with a response, wherein theat least two communications networks further comprise a channelestablisher that establishes a communications channel between the servernode and the client node through the intermediate network element,wherein the server node transmits data packets through thecommunications channel to the client node until the client node sends arequest, via the intermediate network element, to teardown thecommunications channel, and wherein the client node transmitsinformation related to transmission statistics to the server node. 10.The network control framework apparatus as recited in claim 9, furthercomprising: an author provider that provides an author of the at leastone specified rule to trigger least one specified rule at theintermediate network element based on a control method, the controlmethod comprising: a rule to be evaluated when the intermediate networkelement receives the request from the client node destined for theserver node; a rule to be evaluated when the intermediate networkelement receives the response from the server node destined for theclient node; a rule to be evaluated when the intermediate networkelement receives a data packet containing a content sent by the servernode to the client node through the communications channel establishedbetween the server node and the client node; a rule to be evaluated whenthe intermediate network element receives a data packet containing theinformation related to transmission statistics from the client node tothe server node; a rule to be evaluated when the intermediate networkelement receives a specified number of data packets containing thecontent sent by the server node to the client node through thecommunications channel established between the server node and theclient node; and a rule to be evaluated when the intermediate networkelement receives a data packet containing the content sent by the servernode to the client node through the communications channel establishedbetween the server node and the client node after a lapse of a specifiedtimer value measured by a recurrent timer.
 11. The network controlframework apparatus as recited in claim 1, further comprising: acontroller that uses a set of parameters in the at least specified ruleto control a content or a content delivery session to achieve deviceindependence in delivering the content, comprising: a set of userpreference parameters comprising preferences of a human user thatconsumes the content; a set of agent capabilities parameters comprisingcapabilities of a software agent employed by the human user to retrievethe content; a set of device capabilities parameters comprisingcapabilities of hardware employed by the human user to retrieve thecontent; and a set of natural environment parameters comprisinginformation about an environment in which the human user retrieves thecontent.
 12. The network control framework apparatus as recited in claim11, wherein the set of user preference parameters comprises: apreference for the human user that relates to a method of retrieving thecontent; a preference for the human user that relates to a language usedin the retrieved content; a preference for the human user that relatesto presenting the retrieved content; an age group of the human user thatretrieves the content; a gender of the human user that retrieves thecontent; and an employment status of the human user that retrieves thecontent.
 13. The network control framework apparatus as recited in claim11, wherein the set of agent capabilities parameters comprises: a typeof the software agent employed by the human user to retrieve thecontent; a content format supported by the software agent employed bythe human user to retrieve the content; a content language supported bythe software agent employed by the human user to retrieve the at leastone content; and a transmission protocol supported by the software agentemployed by the human user to retrieve the at least one content.
 14. Thenetwork control framework apparatus as recited in claim 11, wherein theset of device capabilities parameters comprises: a type of the hardwareemployed by the human user to retrieve the content; a processor speedand processor family of the hardware employed by the human user toretrieve the content; a memory capacity of a physical storage and asecondary storage of the hardware employed by the human user to retrievethe content; a display depth and a resolution of the hardware employedby the human user to retrieve the content; and an operating system thatruns on the hardware employed by the human user to retrieve the content.15. The network control framework apparatus as recited in claim 11,wherein the set of natural environment parameters comprises: informationrelated to a location where the human user is retrieving the at leastone content; information related to a mobility of the human user thatretrieves the content; and information related to a lighting conditionin which the human user is retrieving the content.
 16. The networkcontrol framework apparatus as recited in claim 11, wherein the at leastone special package is capable of interpreting and evaluating the atleast one specified rule.
 17. The network control framework apparatusrecited in claim 1, wherein said network control framework apparatus isutilized in a communications network.
 18. A network control frameworkmethod for controlling resources at an intermediate network elementconnecting at least two communications networks, comprising: providing agateway functionality by a gateway; performing a network resourcecontrol decision by a rule engine based on at least one specified rule,wherein the at least specified rule is specified according to a rulespecification format; offering a specialized functionality to the ruleengine by at least one special package added to the rule engine;injecting or removing the at least one specified rule to or from therule engine by a rule injector; and distributing the at least onespecified rule to the intermediate network element by: distributingindications in the at least one specified rule to indicate whether atleast part of the at least one specified rule is to be distributed;distributing a signature embedded into a data packet to announce acapability of the intermediate network element that the data packettraversed; parsing the at least one specified rule to determine whetherat least part of the at least one specified rule is distributed;identifying a target network element to distribute at least part the atleast one specified rule; distributing a signal embedded into the datapacket to inform the target network element to distribute at least partof the at least one specified rule; and retrieving at least part of theat least one specified rule distributed to the target network elementfrom the intermediate network element that distributes the at least partof the at least one specified rule.
 19. The network control frameworkmethod as recited in claim 18, further comprising: extracting thesignature embedded in the data packet, by: checking for the signatureembedded in the data packet; checking for a signature formattedaccording to a predetermined data format that is previously stored andhas a matching starting point, an endpoint and a transmission protocol;allocating a new data format when there is no predetermined data formatthat is previously stored specifying the starting point, the endpointand the transmission protocol; purging data stored in the predetermineddata format having the matching starting point, the endpoint and thetransmission protocol; preparing a last-in-first-out data structure;extracting the signature embedded in the data packet and pushing thesignature onto the last-in-first-out data structure; removing eachelement in the last-in-first-out data structure and recording eachelement in the predetermined data format; and recording a number ofsignatures extracted, in the predetermined data format.
 20. The networkcontrol framework method as recited in claim 18, further comprising:parsing the at least one specified rule to determine whether at leastpart the at least one specified rule is to be distributed, by: checkingthe at least one specified rule for syntactical validity; rejecting theat least one specified rule when a syntactical error exists; checkingthe at least one specified rule for a distribution indication;evaluating the at least one specified rule locally when no distributionindication exists; determining a remote intermediate network element todistribute the at least one specified rule to; locally evaluating the atleast one specified rule when no remote intermediate network element isdetermined to exist; checking whether the remote intermediate networkelement contains a special package required by the at least onespecified rule; locally evaluating the at least one specified rule whenthe remote intermediate network element does not have the specialpackage required by the at least one specified rule; and distributingthe at least one specified rule to the remote intermediate networkelement.
 21. The network control framework method as recited in claim18, further comprising: determining a remote intermediate networkelement that the at least one specified rule is to be distributed togiven a predetermined distribution indication, by: locating a signaturein a predetermined data format with a matching starting point, endpointand transmission protocol; determining that no remote intermediatenetwork element exists when no predetermined data format is located;setting a temporary variable as a specified number of intermediatenetwork elements between a specified endpoint in the predetermineddistribution indication; setting the temporary variable to a value ofthe specified number of intermediate network elements in thepredetermined data format when a specified number of intermediatenetwork elements towards or from the endpoint in the predetermineddistribution indication is greater than a number of intermediate networkelements towards or from the specified ending point in the distributionindication, wherein the predetermined distribution indication comprisesa specification of the endpoint and a specification of the number ofintermediate network elements to the endpoint, set the temporaryvariable to a value equal to the number of intermediate network elementsgiven in the predetermined data format minus an original value of thetemporary variable, wherein the distribution indication comprises aspecification of the endpoint and the specification of the number ofintermediate network elements from the endpoint, and sets the temporaryvariable to a value equal to the original value in the temporaryvariable less by one; declaring the remote intermediate network elementto be the network element specified in a signature stored in thepredetermined data format in which the signature has an index in anarray of signatures in the predetermined data format equal to the valuestored in the temporary variable; and declaring that no remoteintermediate network element exists when an index equal to the valuestored in the temporary variable in the array of signatures in thepredetermined data format does not exist.